…avoid FP

…ocks

…treatment

…ixable

…sing

… r=jdonszelmann"

This reverts commit 5dc3c19, reversing
changes made to 11339a0.

will improve the diff for the next commit

- move `is_allowed_vec_method` (a stripped-down version of it, anyway,
  as the function doesn't make sense as is out of context) to utils, as
  it's shared between `useless_vec` and `ptr_arg`
- add another test for non-standard macro brace case
- rm unneeded `allow`s
- rm duplicated tests
- add comments to some tests

…ration_sugg`

This doesn't change any functionality, but will make it easier to switch
to a uniform message in the next commit. Also a nice simplification imo

Diff best seen with whitespace ignored

changelog: [`sliced_string_as_bytes`]: don't fire on
`str[..].as_bytes()`

So I ran into this in some codebase I was working on,
where the lint fired on this line:
```rust
let string: &str;
string[..].as_bytes()
```
So I was trying to understand the rationale behind this lint, and it
says:
> It involves doing an unnecessary UTF-8 alignment check which is less
efficient, and can cause a panic.

This is obviously not true in the case where a `RangeFull` slice is
being taken, since there is no UTF-8 boundary check, and no panic can be
caused. So I created an exemption for `RangeFull`s.

Two other notes:
1. I'm not sure the word "alignment" in the lint's description (quoted
above) is really correct, should probably say "char boundary" instead?
2. I might be missing something, but isn't there a lint for doing
superfluous slice indexing, and then calling a slice method? e.g.
`str[..].len()` or `slice[..].len()`, where `str` and `slice` are `&str`
and `&[T]`, respectively. If we had one, I would expect *it* to fire for
the example code I quoted above.

… expansion (rust-lang#15958)

This means some existing test cases won't get linted anymore, but imo
that's preferable to false-positives.

Fixes rust-lang/rust-clippy#14548

changelog: [`equatable_if_let`]: don't lint if pattern or initializer
come from expansion

First commits fixes a display issue when JS is disabled. Before:

<img width="962" height="144" alt="image"
src="https://github.com/user-attachments/assets/d9ca8077-2486-49eb-9a99-bd396c0d67fa"
/>

After:

<img width="962" height="144" alt="Screenshot From 2025-11-18 14-12-52"
src="https://github.com/user-attachments/assets/a5f0c390-7e3c-4ad5-bb0d-95e0c1a1889b"
/>

The two other commits remove (each) one DOM level in the filters menu.

changelog: none

r? @Alexendoo

…ns (rust-lang#16102)

Currently the `sugg` utility treats all `ExprKind::Match` expressions as
potentially needing brackets, and therefore many lints will add
parenthesis around them. However this includes desugared match
expressions like the `?` and `.await` operators.

In this PR I have updated the utility to only treat match expressions
which include a code block as needing parenthesis, as the other types
have similar precedence rules and expectations to things like member
access and I think can be treated like as such.

While this change is small on paper it touches a large amount of code
due to changing a cross cutting concern, I am happy to add additional
tests if we think it is needed, but I wanted to get a feel for if this
is even a sensible change to be doing and what the expectations were
around the level of testing needed before investing more time into it.

Regarding not putting a specific lint in the changelog, determining all
the lints this could possibly effect would be possible but take some
time, and I wonder if it would be a bit too noisy in the changelog. Open
to suggestions about how best to address that.

fixes rust-lang/rust-clippy#16045

changelog: stop inserting unnecessary brackets around `x?` and `x.await`
expressions in suggestions

changelog: none

See:
https://github.com/rust-lang/mdBook/blob/master/CHANGELOG.md#mdbook-051

changelog: none

r? @ghost

changelog: none